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Abstract — Access control to data in traditional enterprises is typically enforced through reference monitors. However, as more 
and more enterprise data is outsourced, trusting third party storage servers is getting challenging. As a result, cryptography, 
specifically Attribute-based encryption (ABE) is getting popular for its expressiveness. The challenge of ABE is revocation. 
To address this challenge, we propose PIRATTE, an architecture that supports fine-grained access control policies and dynamic 
group membership. PIRATTE is built using attribute-based encryption; a key and novel feature of our architecture, however, is 
that it is possible to remove access from a user without issuing new keys to other users or re-encrypting existing ciphertexts. We 
achieve this by introducing a proxy that participates in the decryption process and enforces revocation constraints. The proxy 
is minimally trusted and cannot decrypt ciphertexts or provide access to previously revoked users. We describe the PIRATTE 
construction and provide a security analysis along with performance evaluation. We also describe an architecture for online social 
network that can use PIRATTE, and prototype application of PIRATTE on Facebook. 

Index Terms — Attribute-based Encryption, Revocation, Access Control, Social Networking 
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1 Introduction 

Access control to data in traditional enterprises is 
typically provided by reference monitors that enforce 
a particular policy This approach, however, creates 
a vulnerability for monitors that are buggy or com- 
promised and thus do not enforce the correct policy 
This is a particular concern in large, distributed en- 
terprises, as well as Online Social Networks (OSNs), 
where recent privacy compromises showcase the dan- 
gers of entrusting privacy controls to social network 
providers 111, pj. The problem gets challenging as 
enterprises outsource more and more data, and rely 
on third party storage servers to enforce the access 
policy 

Attribute-based encryption (ABE) |3j, |5j pro- 
vides an alternative approach to data protection, 
where the ability to decrypt data items is controlled by 
a policy specified in terms of attributes. ABE systems 
mimic the expressiveness of traditional access control 
systems, but use cryptography instead of reference 
monitors. In enterprises, this means that data can be 
sent over channels and stored on media that might 
at some point become compromised without fear of 
a privacy breach. Among several existing schemes, 
Ciphertext Policy ABE (CP-ABE) El is appropriate 
for most applications. In CP- ABE, the encryptor uses 
some public parameters and a policy described over 
attributes to encrypt a piece of data. Different secret 
keys are issued for different sets of attributes. A 
key that has enough attributes to satisfy the policy 
decrypts the ciphertext. 

Various applications can benefit from the flexibility 



and expressiveness of ABE, but require the support 
of frequent revocation. ABE falls short in such areas 
when frequent and immediate revocation of access 
is required. Researchers have proposed revocation 
by attaching an expiry date to the keys (4), (5) or 
introducing proxies |6|. However, existing approaches 
come with their shortcomings either by introducing 
delay in revocation, increasing the size of ciphertext, 
or affecting (re-keying) all the users including both 
the revoked and non-revoked ones. 

In this paper, we present PIRATTE, a proxy-based 
immediate revocation scheme for CP- ABE. Our design 
makes use of a minimally trusted proxy, which han- 
dles revoked users and attributes. Upon revocation, 
no new key is generated for any user, neither is the 
existing data re-encrypted. We believe this feature is 
key for access control in any context where ABE is 
used together with highly dynamic group member- 
ship and large datasets. Note that the proxy is min- 
imally trusted: it cannot decrypt by itself, and even 
if it were compromised, it cannot allow previously 
revoked users to decrypt either. The only assumption 
we hold is that the proxy is updated with a new 
key each time a revocation takes place. PIRATTE 
ensures forward secrecy, backward secrecy with some 
assumptions, immediate revocation of complete or 
partial access, and delegation of access with single 
and multiple key authorities. 

Our Contribution: 

• We provide the construction of our scheme in- 
cluding Proxy-based key /attribute revocation and 
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access delegation, and the security analysis of the 
scheme. 

• We implement a prototype named PIRATTE and 
compare its performance with the CP-ABE scheme 
by Bethercourt et al. |4| (BSW CP-ABE). 

• In addition, we describe a case study that can 
benefit from using PIRATTE. We choose OSN since 
recent research in OSNs proposes the use of cryp- 
tography to enhance privacy (71, (8), f9). However, 
they are not completely successful because of some 
shortcomings of existing cryptographic schemes. 
We also present an application of PIRATTE running 
on Facebook platform. 

Roadmap: 

The rest of the paper is organized as follows. We 
briefly discuss background information on CP-ABE 
and the base revocation scheme in Section [2] Next, we 
provide a detailed description of our construction in 
Section [3] Section [I] discusses the security of our con- 
struction. We describe the applicability of PIRATTE 
to OSNs in Section [5] We describe our performance 
analysis and the Facebook application in Section J6l 
related work in Section [7} and conclude in Section [8f 

2 Background 

In this section we describe some background informa- 
tion necessary to understand our scheme. We describe 
two cryptographic schemes that form the foundation 
of our approach. 

2.1 Attribute- Based Encryption 

Cryptography can be used to enforce access control 
to information by encrypting data such that only au- 
thorized users can decrypt it. However, with standard 
public-key cryptography, it is necessary to explicitly 
enumerate all of the users who may decrypt each data 
item. While it is possible to issue group keys, this 
creates complex key management issues and several 
problems still remain. 

Attribute-based encryption provides a better solu- 
tion for defining fine-grained access control to groups 
of people. With ABE, a user Alice assigns sets of 
attributes to other users (we will call these users 
Alice's contacts) and issues the corresponding secret 
keys. She encrypts data items using policies expressed 
in terms of plain attributes that defines what attributes 
one must have in order to decrypt the piece of data 
(this variant is called ciphertext-policy ABE; key -policy 
ABE reverses the process, with attributes assigned to 
data items and policies to keys). 

ABE can support complex policies, such as "(Friend 
OR Co-worker) AND Neighbor". ABE also explicitly 
prevents collusion between users: if Bob is Alice's co- 
worker, and Carol is her neighbor, they cannot com- 
bine their attributes together to satisfy the above pol- 
icy if neither of them satisfies it individually. Finally, 



ABE provides public-key functionality, allowing, for 
example, Bob to encrypt a message with Alice's public 
key to be decrypted by her contacts to whom Alice 
assigns secret attribute keys. 

We can formally define a CP- ABE scheme by four 
algorithms with an option for attribute delegation |4|: 

• Setup. This algorithm takes security parameters 
and generates a public key PK and master secret 
key MK. 

• Encrypt(PK, M, P). This algorithm takes the pub- 
lic key PK, a message M, and a policy P and 
generates a ciphertext CT encrypted with P. 

• Keygen(MK, S). This algorithm uses the master 
secret key MK to generate a secret attribute key 
SK using the attributes in the set S. 

• Decrypt(CT, SK). This algorithm decrypts a ci- 
phertext CT to plaintext M as long as the set 
of attributes S in SK satisfies the policy P that 
was used to generate CT from M. (The policy is 
implicitly encoded in CT.) 

• Delegate (/Si^, S). The delegate algorithm takes as 
input a secret key SK for some set of attributes S 
and a set S C S. It outputs a secret key SK for the 
set of attributes S. 

2.2 Revocation Scheme 

To support practical revocation in PIRATTE, we adapt 
the broadcast revocation scheme developed by Naor 
and Pinkas to prevent digital piracy |10|. The scheme 
uses Shamir secret sharing [11| to create shares of 
a secret key, where t + 1 shares are necessary for 
reconstruction, and gives one share to each user. 

During regular operation, the distributor broadcasts 
t random shares, which lets any user to reconstruct 
the secret key by combining the shares with his or 
her own. To revoke up to t users, the distributor 
broadcasts their shares instead of the random ones. 
Any non-revoked user still has t + 1 distinct shares 
and can reconstruct the secret, whereas the revoked 
users do not have enough information even if they 
all collude. 

3 Construction 

3.1 Assumptions and Basics 

Before going into the details of the construction, we 
present some basic mathematical assumptions, and 
the details of CP- ABE and the revocation scheme used 
in PIRATTE. 

Bilinear Pairing 

Let Gi, G2, and G T be multiplicative cyclic groups of 
prime order p, and e a map (Gi x G2 — > Gt)- Let gi and 
g 2 be generators of Gi and G2 respectively (G^ = (gi)). 
If e G u v e G 2 and a,b e Z p , e(u a ,v b ) = e(u,v) ab 
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and e(gi,g 2 ) ^ 1, then e is called a bilinear pairing. If 
Gi = G2, it is called a symmetric pairing, otherwise 
the pairing is asymmetric. 

Secret Sharing 

In Shamir's secret sharing scheme (TT), a secret s in 
some field F is shared among n parties by creating 
a random polynomial P G F[x] of degree t such that 
P(0) = s. The z-th party gets the share (i, P(i)). Given 
any t + 1 shares P(xo), . . . , P(x t ), it is possible to 
recover P(0) using Lagrange interpolation: 

t 

P(0) = V A,P(x,), where \ = T\ , Xj , 



BSW CP-ABE Scheme 

The algorithms in CP-ABE due to the Bethencourt 
et al. are described below. Though CP-ABE uses 
symmetric pairing, it can be implemented using an 
asymmetric pairing as well. 

• Setup: The key authority KA generates a public 
key PK, and a master secret key MK: 

PK = G 1 ,g,h = gP,e(g,g) a 
MK = (f3,g a ) 

where random a,/3 G Z p , Gi = (g), |Gi| = p 

The PK also contains an extra component / = g 1 ^ 
to support attribute delegation. 

• Encrypt(PK, M, t): A policy is represented as an 
access tree structure r with the attributes at leaves 
and threshold k-oi-n gates at intermediate nodes. 
Each node is associated with a polynomial q x of 
degree d x/ where d x is 1 less than the threshold 
value k of that node. The polynomials are of degree 
for OR gates and leaves. The secret s (random 
s G Zp) to blind the data M is associated with the 
polynomial at the root of the tree, i.e., ##(0) = s. 
The sharing works in a top down manner: for all 
other nodes, q x (0) = q pa rent(x) (index (x)). index(x) 
returns a number between 1 and num associated 
with x where num is the number of children of 
parent(x). Let Y be the set of leaf nodes in r. The 
ciphertext CT is: 

CT=(T,C = Me(g,gr,C = h s , 

VyeY:C y = g^ {0) ,C' y = H{att{y)fy^) 

Here, i^:{0,l}*— ^Giisa hash function, modeled 
as random oracle, that maps string attribute to 
random element of Gi. 

• KeyGen(MK, S): The secret key SK correspond- 
ing to a set of attributes S is (random r, rj G Z p ): 

sk =(d = g ^y^ 

VjeS:D j =g r Hti) r ',D' j =g r ') 



Dj,Dj for each attribute are blinded by rj, and 
all the components are tied together using r in 
D. This prevents attributes of different users from 
being combined together and provides collusion 
resistance. 

• Decrypt(CT, SK): The goal of decryption algo- 
rithm is to find out e(g,g) as . It finds out the secret 
q x (0) at each node x blinded by the random value 
r. A secret key SK that achieves dR such secrets at 
the root R, can solve the polynomial qn and decrypt 
the ciphertext. A recursive algorithm Decrypt Node 
pairs Di and D[ (from SK) with C x and C' x (from 
CT) respectively and returns e(g,g) rqx ^ for each 
leaf node x in the r in CT, iff i = attr(x). i G S 
is the set of attributes for which a user is assigned 
SK. 

At each non-leaf node, Lagrange interpolation is 
used on at least k (the threshold value of the node) 
such e(g,g) rqz0 received from its children z, to cal- 
culate e(g,g) rq ^°\ Let A = e(g,g) rqR ^ = e(g,g) rs . 
Then C,C,D and A are used in bilinear mapping to 
cancel out e(g,g) rs , and retrieve M. Further details 
can be found in (i). 

• DELEGATE(/Si^, S). The delegate algorithm re- 
randomizes the relevant set of attributes S C S of a 
secret key SK assigned for some set of attributes S. 
It outputs a secret key SK for the set of attributes 

S. „ 

SK =(D = Df, 

VkeS:D k = D k g f H(kY\b' k = D' k g^) 

Revocation Scheme of Naor and Pinkas 

This scheme consists of 2 phases: 

• Initialization: The group controller generates a ran- 
dom polynomial P of degree t over Z p . It sends a 
personal key (I u , P(I U )) to each user u with random 
identity I u . This process is performed only once for 
all future revocations. 

• Revocation: The group controller learns the ran- 
dom identities of t users I Ul , . . . , I Ut that should 
be revoked. At most t users can be revoked 
since the scheme depends on polynomial secret 
sharing. It then chooses a random r, and sets 
the new key to be g rP ^\ that would be un- 
known to revoked users. It broadcasts the message 
g r , (I Ul ,# rP ( J -i)), . . . (I Ut ,9 rP{Iut) ) encrypted with 
the current group key. Each non revoked user can 
compute g rP ( Iu ^> and combine it with the broadcast 
values to obtain g rP (°) using Lagrange's interpola- 
tion formula. Further details can be found in (To) . 

3.2 Proxy-based Complete Key Revocation 

In this section we describe how to completely re- 
voke keys from parties. That means, all the privileges 
granted by the key authority are revoked from one or 
more contact(s). This construction allows revocation 
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of up to t users at a time since it is based on the 
scheme in [ 10 1 described before. 

Intuition: 

The master key MK contains a polynomial P of 
degree t. P(0) is used to blind users' secret keys. Each 
user u also gets a random share P{u) of P(0) in her 
key. The proxy key consists of t such shares and is 
used to convert a part of the ciphertext for decryption. 
Whenever access is revoked from someone, her share 
becomes a part of the proxy key, and eventually the 
converted ciphertext. Therefore, the revoked user does 
not have enough points, i.e. (t + 1) points to unblind 
her key and the ciphertext and decrypt it. However, 
non-revoked users can always combine their secret 
keys with the ciphertext and hence decrypt it. 

When no one is revoked, the proxy key consists of 
t random P(u) points. Since the revocation is based 
on polynomial secret sharing, and the degree of the 
polynomial is t, the scheme is limited to maximum 
t revocations. Though each time t different users can 
be revoked, the total number of users in the system 
is not limited. 

- Setup: The key authority KA randomly generates 
a polynomial P of degree t (the maximum number of 
revoked users) over Z p , sets the broadcast secret P(0) 
to be used after revocation, and randomly chooses 
a,/3 G Z p . She generates PK and MK as follows: 

PK = Gi,G 2 ,0i,02,ft = 9i^e(g u g 2 ) a 
MK = f3,g%,P 

- Encrypt(PK, M, r): Let Y be the set of leaf 
nodes in r. Data M is encrypted to get the ciphertext 
CT. Other than the asymmetric groups, this algorithm 
works exactly the same as in BSW CP- ABE. 

CT =(t,C = Me(g u g 2 r s ,C = h s = g? s , 

WyeY:C y = g q ^\ C' y = H{aU{y))^ = £ 2 W0) ) 

where H : {0,1}* -> G 2 and h y = log g2 H(att(y)) 
(used for notational convenience only). 

- KeyGen(MK, S): The algorithm KeyGen outputs 
the secret key corresponding to the set of attributes 
S, blinded by P(0) from MK. We introduce an ex- 
tra component — D" — that in addition to attribute 
information contains user information. Without loss 
of generality, we assume user Uk receives this key. 

SK = (D, Vj G S : (Dj , D f - ,D")), where 

D = gt +r)/ ^ 

D J =g r 2 H( J y^=g^ h ^ \ 

D fJ = ^P(u k ) =g r j P(u k ) 

- ProxyRekey(PK, MK, RL): Whenever the KA 
wants to revoke keys from social contacts, she creates 



a list of revoked users RL with their identities u if 
i G {1, ...,£}, and evaluates the corresponding P(ui) 
using MK. She gives the proxy key PXK to the 
proxy. In case of no or fewer than t revocations, the 
KA generates random (x,P(x)) other than the actual 
user identities, to make PXK of length t. 

PXK = \Jm G RL : {u h P( Ui )} 

- CONVERT(PXK, Vy G Y : C y , u k ): The proxy 
uses its key PXK and the decryptor's identity u k to 
calculate C' y ' as follows: 

Vi,jG{l,...,t}, fc£{l,...,*}, 

Uk ~ Ui -M: (Uj - Ui) 

My eY : C" = (C )^ =1 XiP ^ = g %v q vW ^*=i A * p ( n *) 

Since the user secret key SK is blinded by P(0), she 
needs C' y ' in addition to C y and C' y for decryption.The 
proxy also calculates and gives it to the user u^. 

- Decrypt(CT, SK): The decryption steps involve 
one extra pairing than BSW CP-ABE at each leaf node 
of the policy. For each leaf node x where i = attr(x), 
if i G S, (S is the set of attributes for which SK is 
issued) then, 

DecryptNode(CT, SK, x) 
= e(C XJ D t ) 

e(D'',C> x )^e(D',C») 

e(gi , 92) rqx (°) +/wP (°)^ (°) 
" e(^i,^ 2 ) r</l< ^ (0)AfcP(Mfc) e(^i,^2) r<,l<9aB(C)) ^s=i x s p M 
e(gi , g2) rqx (°)+^ riP (°)^ (°) 

" e(g u g 2 y^ qx (0)P(0) 

Otherwise Decrypt Node returns ±. The rest of the 
decryption is the same as CP- ABE. For each child z of 
a non-leaf node x, it calculates F z = e(gi, g2) rqz ^ - Let 
S x be a threshold-sized arbitrary set of children of x, 
such that F z ^ _L Then interpolation and pairings are 
used to calculate e(gi,g2) as , and hence retrieve M. 

F x = \{ F x \[i = index(z), 

zes x 

Xi calculated over the indices of z G S x ] 

= ri( e (5i.52)^ (o) ) A * 

zes x 

- II (e(g 1 ,g 2 ) rq '"' rent ^ {index{z) Y', [discussed in EI] 

zes x 

zes x 

= e($i, rA * fe(i) 
= e(g 1 ,g 2 ) rq -M 
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Let A = e(g u g 2 ) rqR{0) = e(g u g 2 ) rs at the root R. 
Decryption proceeds as follows, 



C 



e(C,D) 
A 



Me(g u g 2 ) c 



e{gi,g2) as+rs 



M 



Decryption proceeds are follows: 

DecryptNode(CT, SK, x) 
= e(C x ,Dj) 

e{g 1 ,g 2 ) qx ^ r+f+hiriP ^ )+hifi) 
= e (g u g 2 )(riP{u k )+fi/\ k )h iqa! (o)\ k 



Explanation of Asymmetric Group: 

We use different groups for C[ and (i is the 
attribute). The user gets C[ converted to C'( = C[ a 
(a = Y^j=i ^jP{ u j)' explained in the Convert algo- 
rithm) by the proxy However, if both C[ and D[ 
belong to the same group, and the user gives the 
proxy D[ instead of C[, she will get (£>-) a = g ari . 
She will also get which she can use to get 
D'l Xk = g x kP(u k )r^ Multiplying these two, she gets 

gri (a+\ k P(u k )) = ^P(O) g he can uge thig lagt value 

to decrypt any ciphertext without using the proxy, so 
the revocation is no longer effective. Therefore, we use 
asymmetric pairing, where C[ and D[ are in different 
groups and mapping of D[ into the C[ group is not 
possible. 



3.3 Delegation of Access 



e(g u g 2 ) rihiqxi0) ^Ui x j p M 

e ^g 1 ^g 2 ^r+r)q x (0)+h i r i P(0)q x (0)^h i r i q x (0) 
e(gi, g 2 Y ihiQx ^ ^kP{u k )+hi riq x (0) 



e(gi,g 2 ) rihiqA0) 52j=i x 3 p M 

e(9l , 92) (r+f) ^ (°)+^ r ^ P (°)^ W+hifiQx (0) 
~ g^^^n/i^.WCE^i A j P(n i )+A fc P(n fc ))+/i i r i g a; (0) 

e ^g 1 ^g 2 ^r^r)q x (0)+h i r i P(0)q x (0)^h i r i q x (0) 
~ e (^ l5 g 2 yih i q x (0)P(0)+h i r i q x (0) ' 

fc^{l,2,...,*} 

Let A = e(^i,^ 2 ) (r+f)gR(0) = e(g u g 2 )^> for the 

root node. The rest of the decryption proceeds as 
follows, 



6 -Me( 9l , 92 r e(9 " 9a) ' r+ "" 



e(C,D) 



e(gi,g 2 ) as+rs+ ™ 



M 



We design delegation of attributes in PIRATTE in two 
settings - 1) When all the keys to different parties are 
issued by a single key authority, and 2) When keys 
are issued by multiple key authorities. 



3. 3. 1 Single Key Authority 

In the single authority setting, a user u k gets a secret 
key SK from key authority KA, and delegates one 
or more of the attributes that she possesses in her 
secret key to another user. As long as is not re- 
voked, the delegated key can be used for decryption. 
The delegation process is as follows. The delegation 
algorithm takes in a secret key SK issued for a set 
of attributes S and delegates one or more attributes 
from this set. The delegated key SK is generated 
for the subset of attributes S C S. For delegation 
in single authority setting, an extra public parameter 
/ = is introduced in the public key PK. Let 

random r G Z p , and random Vj G S, fj G Z v . 



SK = (D,Vj G S : (DjiD^D'j)), where 
D = (D)f 



(a+r+r)/P 
9 2 



Dj = (DMH(jp 



D» 



fj/ X k 



r+r+hjrjPW+hjrj 
9 2 

rjP(u k )+rj/\ k 

9i 



3. 3.2 Multiple Key Authority 

The second version of delegation of access is designed 
with a distributed setting in mind, i.e., when secret 
attribute keys are issued from different key authorities 
to different users. In this setting, A generates keys 
for B and B generates keys for C; i.e., B is a contact 
of A and C is a contact of B. Again, the delegation 
algorithm takes in a secret key SK issued for a set of 
attributes S and delegates one or more attributes from 
this set. In the following construction, we will show 
how B delegates a key SK for the set of attributes S 
generated by A for B, to C. 

SK = (D,Vj G S : (Dj,D' p D'!)), where 



(a+r)//3 



D = g K 2 

Dj = g r 2 H( 3 Y^\D' = g{\D" = {D') p * 



where random r, rj G Z p , Pa is the polynomial in A's 
MK, and B is Bs identity. 

Attribute delegation allows B to delegate some 
subset of attributes S C S to his contact C. B re- 
randomizes SK for C for a set of attributes S C S. 

SK = (A VjeS : (Dj.DpDj, D'»)), where 
jjrj = (d") 1/Pb ^\D'^ = (p'j) p B(P)/P B (Si) 

where P# is the polynomial in B's MK, and C is C's 
identity. 
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To decrypt a ciphertext CT encrypted with A's 
public parameters, A's proxy calculates C y ' A = (C' y ) XA 
and \b, B's proxy calculates Cy B = (C y ) Xl3 and 
Ac, and gives it to C. Here, C' y is from CT, and 
X A and Xb are revocation information for A's proxy 
and B's proxy respectively, calculated as X A = 
Ys%i\PA{ui),X B = Y?jLi^j p B(uj). ui and u 3 - are 
the revoked users by A and B respectively, A^ and 
Xj are the Laggrange's coefficients for corresponding 
revoked users, and t\ and t 2 are the parameters for 
the maximum number of revoked users by A and B 
defined in their MKs. Xb and Ac are the Laggrange's 
coefficients for B and C respectively B's identity is 
conveyed to C as a part of the communication for SK, 
or any other way C does a modified bilinear pairing 
in the DecryptNode, and finally decrypts the data. 

DecryptNode(CT, SK, x) 

= e(C g ,A) 

~ e(D^ C<< B y*e(D<<<, C> x )^ce{D>, C >' A ) 
= e(C x ,Dj) 

e(^o,^i) n/la; ^ (0)XBABPA(B)/PB(0) 
1 

e (g yq x (0) h x q x (0) P A (0) 
~~ e(go, g i yi h xQx(0)X B PA(B) e ^g Q ^ g^nhxqxWXA 

e(g , gi) rqx ^+ Tihxqx ^ PA ^ 
e(go, gi) rihx( ixW PA W 

= e( 50 ,5i) rfe(0) 

The rest of the decryption proceeds as before. If A 
revokes B or B revokes C, the decryption will not 
succeed since both the proxies participate in the de- 
cryption, and the delegated secret key SK contains 
information about all A, B, and C. 

3.4 Proxy-based Attribute Revocation 

In this section, we describe how to revoke one or 
more attributes from a given secret key. This is useful 
since often the KA may want to merely revoke a few 
attributes from her contacts instead of the whole key. 
For instance, user A might want to remove friend 
attribute from B, but B still remains in her colleague 
group. 

Intuition: 

The idea is basically the same as complete key revo- 
cation. The master key contains one polynomial Pi 
of degree U for each possible attribute i that the KA 
can assign. Any attribute can be introduced later by 
introducing a new polynomial in the MK. Pi(0) is 
used to blind the corresponding attribute in the secret 
keys. Each user u also gets a random share Pi{u) of 
Pi(0) in her key. The proxy key consists of U such 
shares for each attribute in the policy used in the 
ciphertext. Whenever some attribute is revoked from 



some user, that share becomes a part of the proxy 
key, and hence the converted ciphertext. Therefore, 
the revoked user does not have enough points, i.e. 
(U + l) points for that specific attribute to unblind her 
key and the ciphertext and decrypt it. However, non- 
revoked users can always combine their secret keys 
with the ciphertext and hence decrypt it. As before, 
when no attribute is revoked, the proxy key consists 
of U random points for each attribute i. 

- Setup: The KA generates one polynomial P y ran- 
domly over Z p for each attribute y £Y' where Y' is an 
initial set of attributes in the system, and sets P y (0) as 
the secret to be used to revoke the attribute. To revoke 
an attribute from t users at a time, the degree of the 
polynomials is chosen to be t. New attributes can be 
introduced later by randomly generating polynomials 
for them. Finally, she randomly chooses a,/3 £ Z p . 

PK = Gi,G 2 ,0i,02,ft = 9i^(g ll g 2 ) a 
MK = /3,g2,V yeY >:Py 

- KeyGen(MK, S): The components of the secret 
key are similar as before except that the polynomial 
in each is specific to the attribute represented by 
the component. Again, without loss of generality, we 
assume user receives this key. 

SK = (D,Vj £ S : (Dj,DpDj)), where 

D = gt +r)/ ",D 3 = g' • H(jy> p >W = gl+ h n p &\ 
D'j = g r ^D" 3 = (D' 3 ) p ^ = Q r f^ 

- Encrypt(PK, M, r): Encryption is similar as in 
complete key revocation. 

- ProxyRekey(PK, MK, My £ Y : RL y ): To revoke 
an attribute y £ Y from t contacts, the KA creates a 
t-sized list RL y = {i^}, iE{l,...,t}of revoked users 
for that attribute, and evaluates P y {ui) using MK. In 
case of no or less than t revocations, she generates 
random (x,P y (x)) to make RL y of length t. The set 
of users from whom different attributes are revoked, 
may or may not overlap. Without loss of generality we 
assume that the sets of revoked users don't overlap. 
The proxy key PXK is constructed as follows: 

PXK = \/y £ Y^m £ RL y : (u u P y ( Ui )) 

- Convert (PXK, Vy £ Y : C y ): The proxy uses its key 
PXK to convert the attribute relevant components C' y 
received from user Uk to C' y ' as follows: 

X\ = — TT — r, 

U k - Ui ±1 [Uj - Ui) 

Vui,Uj £ RL yi Uk £ RLy, RLy £ PXK 

\/y£Y:Cy= (C' y )^=i x i p y^ = ^^ (0) E ^ xV i p yM 
My £Y the proxy also calculates and gives X v k , to Uk- 
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- Decrypt(CT, SK): For each leaf node x where i = 
attr{x), if i G S (S is the set of attributes for which 
SK is issued), and i is not revoked from Uk then, 

DecryptNode(CT, SK, x) 
= e(C g ,A) 

e (^ l5 ^ 2 )^(0)+^r i P i (0)g cc (0) 

" e(^i,^2) r</l<ga(0)A * p<(ufc) e(^i,^2) r<,l<9as(0) ^=i A 5 A(n ^ 
e(#i , #2)^ (°)+^ riPi (°)^ (°) 

e (p lj p 2 )n/ii^(0)(AiP i (u fc )+E5-=i AjPiCuj)) 
e (^ l5 ^ 2 )^(0)+^r i P i (0)g :r (0) 



e(g 1: g 2 ) Tihiqx ^ Pi ^ 



-,fcg{l,2,...,t} 



Otherwise Decrypt Node returns _L The rest of the 
decryption is as before. In summary, if an attribute 
i is revoked from user u, he can not do pairing on C" 
and D[. He can continue to use components related 
to his other unrevoked attributes. Therefore, some of 
his attributes are revoked whereas some continue to 
be active. 



4 Security Analysis 

First, we need to define the requisite security prop- 
erties for CP- ABE with Proxy Revocation. We present 
the definition for identity-based revocation; the defi- 
nition for attribute-based revocation is analogous. We 
base our definition on the security model defined by 
Bethencourt et al. [4|, with the addition of revocation 
and proxy operations. In this game, all encryptions 
remain secure even when the adversary compromises 
the proxy and obtains its key material, as long as this 
happens after the most recent revocation. 
Setup. The challenger runs the Setup algorithm and 
gives the public parameters, PK, to the adversary. 
The challenger also runs ProxyRekey(PK, MK, 0) to 
generate a proxy key PXK. 

Phase 1. The adversary makes repeated queries to 
Keygen to obtain keys for users u\, . . . , u qi with sets 
of attributes Si,...,S qi . The adversary also interacts 
with the proxy by calling CONVERT with the input 
({C , 1 ,...C , r },u k ) for C[ G Gi and u k G Z p/ at which 
point the challenger runs the CONVERT algorithm 
with the stored proxy key PXK. Finally, the adver- 
sary may call PROXYREKEY by supplying a revocation 
list RL. This will cause the challenger to update the 
proxy key PXK. 

Challenge. The adversary submits two equal length 
messages Mo and Mi and an access structure A*. The 
adversary also supplies a new revocation list RL*. 
RL* and A* satisfy the constraint that, for each user 
Uk, either Uk G RL* or Sk does not satisfy A*. 

The challenger flips a coin to obtain a random bit 
b and returns M5 encrypted with the access structure 



A*. Additionally, it runs PROXYREKEY (Pif, MK, RL) 
and returns the resulting key PXK to the adversary. 
Phase 2. The adversary makes repeated queries to 
Keygen to obtain keys for users u qi +\, . . . , u q2 with 
attribute sets S qi +i, . . . , S q2 . The new keys have to 
satisfy that if Uk £ RL* , then Sk does not satisfy A*. 
Guess. The adversary outputs a guess b' of b. 

The advantage of an adversary is defined as Pr [b' = 

b\-\. 

Definition 1: A ciphertext-policy attribute-based en- 
cryption with proxy revocation scheme is secure if all 
polynomial time adversaries have at most negligible 
advantage in the above game. 

4.1 Proof Sketch 

We can prove the security of our scheme using a 
variant of a generic bilinear group model. Note that 
since the security of the original CP- ABE scheme relies 
on the generic bilinear group model, the assumption 
we make is only slightly stronger than the original. 
In particular, we must work within an asymmetric 
bilinear group, with a pairing of e : Gi x G2 — » Gt, 
such that there is no efficiently computable isomor- 
phism from Gi to G2. (In a symmetric bilinear group, 
a user could submit D'- to CONVERT and recover 

g J , obviating the need to use the proxy in further 
decryptions.) This is believed to hold true for MNT 
curves (12). 

The generic asymmetric bilinear group model. Con- 
sider three random encodings of the additive group 
¥ p represented by injective maps ^1^2,^ ' F p — >> 
{0, l} m , where m > 3 log p. We will define Gi,G 2 ,G T 
as the range of the respective map. We are given 
access to a group action oracle for each group and 
an oracle for a non-degenerate bilinear map e : Gi x 
G2 — Gt (we will refer to the ranges of V^V^^t 
as Gi,G2,Gt, respectively). We are also given oracle 
access to the isomorphism (j) : G2 — » Gi and a hash 
function H : {0, 1}* G 2 . Finally, we let g { = ^(1) 
fori = 1,2. 

Theorem 1: The construction presented in Section [3] 
is secure under the generic asymmetric bilinear group 
model. 

We sketch the main argument here; most of the rest 
of the details are similar to the proof presented by 
Bethencourt et al. (4). 

Sketch: First of all, we can assume that no "unex- 
pected collisions ,/ happen between the maps, meaning 
that if we keep track of the algebraic expressions 
passed to ipi,ip2,ipT, and </>, two values are equal if 
and only if the expressions are symbolically equiva- 
lent. This assumption is true except for a negligible 
probability. 

For simplicity of presentation, we will assume that 
A* contains a single attribute Aj for some j. Then after 
phase 2, the adversary has the following elements 
available: 
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d : gi,g p 1 ,c = 5 r,Ci = 9i(= gl m ),c> 9 r, 

where s is the random secret used to encrypt the 
challenge message and hj is implicitly defined such 
that = 52 \ 

G 2 : g2 ,D = g r^ W ,D j = g r h ^°\ 
Dj = 9 r 2 ^,D'J = g^ M 

for each queried user Uk where Aj G Note that we 
can ignore all Dy for f ^ j because, as with CP- ABE, 
they will not help with decryption. 

GT:e(g u g 2 r,M-e(g u g 2 r s 

In addition, the adversary knows itk,P(uk) for all 
the revoked users in RL*. Note that we can ignore 
any other elements of Gi obtained through calls to 
CONVERT during Phase 1, or through calls to the iso- 
morphism. This is because in order to guess correctly 
with a non-negligible probability, the adversary needs 
to compute e(gi,g2) as - Since there are no occurrences 
of s in G2, each pairing must involve gf k for some k, 
and hence be derived from C, Cj, or Cj. 

The adversary can compute e(C, D^) = 
e(gi,g2) as+TuS , hence computing e(gi,g 2 ) as is 
equivalent to computing e(gi,g 2 ) r ™ s for some user 
u. Note also that the secret keys obtained for other 
users are not helpful here, for the same reason as in 
original CP- ABE. Algebraically, the adversary must 
solve the following equation: 

e(g 1 ,g 2 Y^ = e[g x 1 ,( y D^ ) y)e(g 1 ,g 2 r 

where x,y, and z are derived from the available 
elements other than Note that x,y ^ 0, since 

otherwise there is no way to introduce r u into the 
right-hand side. However, the rest of the values are 
independent of P(0), since the only values of the poly- 
nomial available to the adversary outside of are 
P(uk) for Uk G RL*, and thus are not sufficient to 
determine P(0). 

□ 



hjS 



5 Case Study: Social Networks 

Online Social Networks (OSNs) such as Facebook, 
Google+, Twitter, and Linkedln are becoming one of 
the most popular ways for users to interact online. 
Besides personal communication, OSNs provide the 
perfect platform for online games and other applica- 
tions. Users share personal information with the social 
network provider, and trust the provider to protect 
their sensitive information. However, this introduces 
privacy risks, as the collection of information is an 
attractive attack target (13) . Insiders can also release 
private information either intentionally or acciden- 
tally (14) , (15) . Several recent privacy compromises 
have thrown these issues into sharp focus (T), |2) . 



These issues have motivated researchers to consider 
a paradigm shift, where instead of trusting social 
network operators and being dependent on them to 
enforce privacy, users are in control of who views 
their data, for example, via encryption (7), (8), (91, 
1 16]. Fine-grained access control is a key challenge 
in this space; for example, Facebook and Livejournal 
have rolled out mechanisms to specify access control 
policies for each post, as the data items are usually 
destined for a subset of friends, or groups. 

Persona (7| is a state-of-the-art design that proposes 
the use of ABE to enable fine-grained access control. 
In OSNs, ABE allows users to have complete control 
over who can see their data, free from the whims of 
the OSN provider. A user can create groups by assign- 
ing different attributes and keys to her social contacts, 
and then encrypt data such that only particular users 
having the desired set of attributes can decrypt it. This 
provides information protection from unauthorized 
users on the OSN, third-party application developers, 
and above all the OSN provider itself. 

However, groups are dynamic and therefore user 
attributes may change over time. This could be be- 
cause of change in location, work environment, or the 
nature or strength of the relationship with a contact. 
Recent studies have shown that the user interaction 
graph is much less dense than friendship graph | |T7| , 
indicating that users interact most frequently with a 
small group of friends, further validating the need 
for fine-grained access control. Moreover, the churn 
rate for the interaction graph has been shown to be 
quite high (17) , motivating the need for access control 
mechanisms to support dynamic groups. 

Persona and similar designs introduce significant 
overhead for group membership changes, especially 
when a contact is removed from a group: all other 
members of the group must receive a new key; addi- 
tionally, all existing data items destined for that group 
must be re-encrypted. This does not scale when group 
sizes are large and group churn rate is high. 



Step 1 I | | Data | | colleague OR (friend AND neighbor) 
Step 3 KeyProxy (Revoke u 1? u 2 ) 




Uo Modified CT„ 



Key Assignment 



Step 5 Decrypt iff not revoked 



Fig. 1. Architecture of EASiER- OSN Built Using 
PIRATTE 

We propose an architecture for OSN using PIRATTE 
as the underlying cryptographic scheme. Encryption 
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successfully hides information from unintended par- 
ties. Traditional OSNs allow people to establish only a 
common relationship with each other by adding them 
as friends. Further specialization is achieved by creat- 
ing lists and adding friends to that list. Relationships 
based on attributes make this task more expressive. 

Figure [T] shows the architectural overview of an 
OSN built using PIRATTE. We call this architecture 
EASiER 1 18 1. Users in EASiER become their own 
key authorities, define relationships by assigning at- 
tributes and relevant keys to the parties, and en- 
crypting data under a policy that, if satisfied, allows 
decryption to the intended parties. For instance, user 
A assigns keys for attributes (colleague, neighbor) to 
user B and encrypts data for the policy 'colleague OR 
(friend AND neighbor)'. 

As mentioned earlier, the user interaction graph is 
different from the friendship graph. People interact 
with a subset of their defined contacts most of the 
time. Recent privacy setting changes in wall posts 
in Facebook also supports this fact. This requirement 
needs ABE in OSNs to consider revocation of ac- 
cess without re-encrypting all the data and re-keying 
everyone in the group when access is denied to a 
contact. For example, after encrypting data under 
the mentioned policy, user A might want everyone 
except u\ and u 2 in her colleague group to decrypt the 
ciphertext, either temporarily or permanently. Besides, 
A might want to revoke the colleague attribute from 
some of her contacts. PIRATTE provides this option 
by introducing a minimally trusted proxy. 

Upon revocation, the owner supplies enough in- 
formation, in this case, a set of t (the maximum 
number of revoked users allowed) revoked users to 
the proxy to construct a proxy key. The proxy is 
minimally trusted. Hence, the OSN provider or a third 
party can act as proxy. An unrevoked user sends a 
specific set of components of the ciphertext (details 
described earlier) to the proxy. The proxy uses its key 
to change these components such that only unrevoked 
users can use it, mathematically combine it with the 
rest of the ciphertext and their keys, and finally 
obtain the plaintext. Since the conversion involves 
only the lightweight components of ciphertext, it is 
not expensive, as we will demonstrate later through 
experiments. 

However, PIRATTE does not allow the proxy to 
decrypt the data since it does not have the attribute 
keys. A new proxy key, created each time a revocation 
takes place, prevents revoked users to collude with 
the proxy or with each other to get the data. This 
prevents the revoked users from decrypting even old 
data unless they store it somewhere. We argue that 
this is a desirable property: currently trusted contacts 
are not likely to crawl the entire set of social network 
data and store it for later use, but former friends or 
colleagues might try to abuse their former status by 
accessing past data. 



Another example of an OSN that utilizes PIRATTE 
is DECENT, a decentralized architecture for OSN (19| . 
It uses PIRATTE for cryptographic protection, DHT 
for efficient data storage, and an object oriented ar- 
chitecture for flexible data representation. 
Friend-of-friend: 

A challenge in using cryptography to enforce access 
control in OSN is to support degrees of relationships, 
such as friend-of-friend or contact-of-contact to be more 
generic. EASiER handles this challenge by using the 
feature attribute delegation in the distributed setting 
described before. 

In this approach, a user A generates a secret key 
for her contact B with the attributes she wants to 
assign to him. She also adds an attribute named fof 
to the key. B uses the access delegation algorithm 
to delegate this specific attribute (fof) to his contacts, 
for example C. Whenever A encrypts a piece of data 
with the policy attrl, attrl, . . . OR fof C can decrypt 
it with the delegated key that he received from B. 
As in distributed attribute delegation, if A revokes 
B, or B revokes C, the decryption will not succeed 
since both the proxies are required to participate in the 
decryption, and the delegated secret key SK contains 
information about A, B, and C. 

6 Implementation and Experiemntal 
Evaluation 

We implemented the constructions in PIRATTE, as 
described in Section [3] Our implementation involves 
introducing new components as well as modifying 
different parts of the BSW CP- ABE toolkit (20). The 
current implementation supports complete key revo- 
cation and access delegation in a distributed setting. 
Similar techniques can be applied to modify it to 
perform attribute revocation. 

The implementation uses MNT curves (12) with 
159 bit base field. All the experiments were carried 
out on a 2.40 GHz Intel Core 2 Duo, 4 GB memory, 
and running Ubuntu 10.04. We also implemented a 
Facebook application to provide the functionality on 
a social network. The code and the Facebook appli- 
cation are available at jhttp : / /www, sonia jahid. 
|com| and jhttp : / / apps . facebook . com/myeasier 
respectively. 

6.1 Performance Analysis 

We provide some information on the performance 
evaluation of PIRATTE, and compare it with CP- ABE 
both with MNT and super-singular curves. Though 
CP-ABE implementation uses symmetric pairing, we 
use asymmetric pairing for both PIRATTE and CP- 
ABE in our implementation. This provides security by 
preventing key and ciphertext components exchange 
(discussed in Section |3j. The results are shown in 
Figure [2] 
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(d) Proxy Rekey in PIRATTE (e) Conversion Pre-calculation by 

Proxy 

Fig. 2. Performance Analysis of PIRATTE and Comparison with BSW CP-ABE 
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(f) Conversion in PIRATTE 



Key Generation: Key generation time is linear with 
number of attributes both in CP-ABE and PIRATTE. 
Since it does an extra exponentiation, and generates 
an extra component for each attribute in PIRATTE, the 
result is justified. CP- ABE with super singular curve 
requires the least time. 

Encryption: To test encryption and decryption, we 
randomly generated 10 different policies for each of 
the desired number of leaves (1,5, 10,. ..100). Encryp- 
tion is also linear with respect to the number of leaf 
nodes in the policy. We did not make any changes 
to the encryption scheme, so CP-ABE with MNT and 
PIRATTE both take the same amount of time. 

Decryption: Decryption depends on the policy used 
in encryption, and the attributes involved. We gen- 
erated a decryption key with 100 attributes. It has 
the superset of all the attributes used to generate the 
policies, and so satisfies each of them. The decryption 
results are shown with a 95% confidence interval. All 
the lines show the performance when an optimization 
was used to ensure the usage of the minimum number 
of leaves in the algorithm DecryptNode. The required 
time is still below 1 second. 

Proxy Rekey and Conversion: PIRATTE involves 
two extra costs before decryption: re-keying the proxy 
and converting the ciphertext components specific to 
the leaves in the policy. The re-keying results (Fig- 
ure |2d) show that for even 1000 revoked users, the 
time required is less than 0.9 seconds. This should be 
compared with the time required to rekey the rest of 
a group, i.e., generate a new key for everyone, when 
even one person in the group is revoked. 

Conversion primarily involves one exponentiation 
for each of the leaf specific ciphertext components. It 



also calculates X k for the requester u k , and completes 
the XiS for each of the revoked users. We perform an 
optimization by allowing the proxy to pre-calculate a 
portion of the A/s in Convert. With the optimization, 
the proxy needs to do 1 multiplication per revoked 
user to calculate A^. It works as follows: 

X 'i= II U^-y and z; = AJPK) 

[U k - Ui) [U k - Ui) 

V ui e RL, u k RL 

Figure |2e] shows the time required for the proxy 
to do the pre-calculation. Note that this is a one- 
time cost each time the proxy is re-keyed and is not 
faced by users. Figure |2f| shows the time required 
to actually convert a ciphertext. The results are al- 
most equal for the number of revoked users since 
time to do t exponentiation dominates the time to 
do t multiplication. Figure |2f| shows the time for 
500 revoked users. We expect the proxy to be more 
powerful in terms of computing, and hence rekeying, 
and conversion should be faster in practice. A user 
performing decryption only faces the conversion time 
shown in Figure |2f| along with the decryption time 
mentioned earlier. 

Decryption with Delegated Key: We measured the 
time required to decrypt a ciphertext with delegated 
secret key in the multiple authority setting since we 
used it in EASiER. We are interested in just one 
attribute, i.e., fof being delegated for the OSN setting. 
The policies used to encrypt the data contain the fof 
attribute in the form: (attrl, . . .) OR fof Therefore, the 
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decryption needs to verify one attribute in the policy 
Hence, the time required does not depend on the 
number of leaf nodes in the policy, and is constant. 
In our experiment, this time is about 0.34sec. 

TABLE 1 
Element Size 



Group 


Size (bytes) 


Gi 


44 


G 2 


124 


Gt 1 


124 


Z v 


24 



TABLE 2 
Component Size 



Component 


PIRATTE (bytes) 


CP-ABE (bytes) 


Public Key 


1316 


1316 


Master Key 


152 + (t + 1)24 


148 


Private Key 


128 + (a + 212)n 


128 + (a + 168)n 


Ciphertext 


168 + Si + (176 + a) I 


168 + 8i + (176 + a) I 


Proxy Key 


24£ 


NA 


r n 

C y 


124/ 


NA 



Component Size and Communication Overhead: 

Table [2] shows the sizes of the components involved 
in the system for complete key revocation. Size of 
the components for attribute revocation can be cal- 
culated similarly Elements from Gi,G2,Gt, and Z p 
require 44, 124, 124, and 24 bytes respectively to rep- 
resent(Table [!}. Users have to communicate with the 
proxy for conversion by sending C' y , and receiving Cy. 
These are represented using elements from G2. This 
requires 124 bytes to represent (120 for the actual data, 
and 4 for the variable size). Hence, conversion of a 
ciphertext with / leaf nodes in the policy will need to 
transfer 124/ bytes each way. The user also sends Uk, 
and receives back. These are represented using Z p 
which requires 24 bytes. 

Public Key consists of a string describing the pair- 
ing used (980 bytes), gi and h from Gi, g 2 from G2, 
and e(gi,g 2 ) a from G T . Master Key consists of ft from 
Z p , and g 2 a from G 2 in CP-ABE. In PIRATTE, it also 
consists of a polynomial of degree t. The polynomial 
consists of an integer t, and t + 1 coefficients from 
Z p . Private Key consists of D from G2, number of 
attributes n (integer), and n of (Dj,Dj)s from G2 and 
Gi respectively and attributes of length a (string) . 
PIRATTE also contains n of D" from Gi. Ciphertext 
consists of C from G T , C from Gi, and components 
for each node in the policy. Both intermediate (i 
nodes) and leaf (/ nodes) nodes have a threshold k 
(integer), and number of children (0 for leaf, also an 
integer). A leaf node has a string attribute of length 
a, and C y and C' y from Gi and G2 respectively. Proxy 
Key consists of t Z p elements. 

Attribute Revocation: We can estimate the time 
required to perform attribute revocation. All the al- 
gorithms work similarly. The only extra work is in 
Setup where instead of just one polynomial, a poly- 
nomial is generated for each attribute in the system. 



It requires 0.08sec to generate a polynomial of degree 
100 and increases linearly with the degree of the 
polynomial. Hence, generating a polynomial for each 
attribute is scalable. 

6.2 Facebook Application 

Finally, we developed a Facebook application for PI- 
RATTE as a proof of concept. The goal is to present 
a high level idea of how an OSN that uses PIRATTE 
will look like. We focused on Facebook because of 
lack of deployment of decentralized architectures like 
Persona and Diaspora pi) . In the current implemen- 
tation, all protocol functions are performed at our ap- 
plication server. Moreover for convenience, we chose 
the client's proxy server to be the application server 
itself. 

The application retrieves public profile information 
of the users installing it using Facebook API, and uses 
this data as its user profile information. Figures [3a| 
and [3b| depict screen-shots of the same. Data is hidden 
for privacy purposes. 

When a user first installs our Facebook application, 
an account is created in the application server. We 
provide a brief description of the supported function- 
ality. 

• Setup: The Setup button is used to initialize a public 
key PK and a master secret key MK. 

• Key Proxy: The Key Proxy button is used to generate 
a key for the proxy server. This is used to key the 
proxy when there is no revocation. Each revocation 
updates the proxy key, so there is no need to 
manually rekey the proxy with each revocation. 

• Add Attributes: The Add Attributes functionality 
is invoked to define a set of attributes like family, 
coworker, researcher, etc. 

• Key Gen: The Key Gen functionality is used to gen- 
erate keys for Facebook friends who also have 
the PIRATTE application installed. These users are 
assigned specific attributes, with the selection of 
attributes being made from amongst the choices 
defined in the Add Attributes step. 

• Encrypt: The Encrypt button is used to generate a 
ciphertext under a policy defined over the available 
set of attributes. For convenience, application users 
can choose and encrypt userid, about, and gender 
for their contacts which is already retrieved from 
their profile information (if available). 

• Revoke: Users can select one or more contacts to 
whom they assigned keys previously, and revoke 
the keys from them. 

• Decrypt: A user can click on any ciphertext gen- 
erated by a contact who assigned her a secret key, 
and is able to view the plaintext if his/her attributes 
satisfy the ciphertext-policy. When a user clicks 
Decrypt, the ciphertext is converted by the proxy, 
and then the user secret key is used to decrypt the 
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data. Names are not shown in the snapshot because 
of privacy. 

Delegate: The Delegate option is used to delegate 
the f of attribute from the keys a user received to her 
contacts. It shows the list of contacts from whom 
a user received secret attribute keys and to whom 
she can delegate access to. Duplicates and self- 
assignment are prohibited through checks. 
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(b) Revoke 
Fig. 3. PIRATTE on Facebook 

7 Related Work 

7.1 Revocation Schemes 

Attrapadung and Imai address the revocation prob- 
lem in p2) by combining broadcast encryption 
scheme with both CP- ABE and KP-ABE. This scheme 
requires knowledge about the list of all possible users 
during encryption, i.e., attaches one component per 
user to the ciphertext. Knowing the list of all possible 
users in advance is inconvenient for most scenar- 
ios, specifically OSNs. Bethencourt et al. in |4| and 
Boldyreva et al. in (23) propose expiration-based revo- 
cation scheme for CP- ABE and KP-ABE respectively. 
In these schemes, the secret keys (CP-ABE) or the 
ciphertext (KP-ABE) contain expiry time as an extra 



attribute. Time-based revocation may not be a desired 
property in several applications where an immediate 
revocation is necessary. It introduces a window of 
vulnerability, i.e., the gap between the desired time 
from revocation to the actual time of revocation. Os- 
trovsky et al. j24 1 present a new KP-ABE scheme with 
non-monotonic access structure to support negation of 
attributes. Revocation can be implemented by adding 
a NOT-attribute to the policy in private key. However, 
this will require re-keying the users from whom an 
attribute is revoked. 

Lewko et al. in (25j propose a revocation scheme 
with small private keys. However, their approach also 
increases the size of the ciphertext by incorporating 
the list of revoked and unrevoked users with it. 
In p6) Hur proposes a revocation scheme for CP- ABE 
where each leaf node, i.e. attribute in the policy used 
to encrypt the data contains a group of users who 
possess that attribute. The scheme consists of a key 
generation center (KGC) and a data storing center 
(DSC). The DSC is equivalent to the proxy in our 
proposed scheme. However, the approach requires 
secret key update for all the users of an attribute 
group from which at least one user was revoked; this 
also includes the non-revoked users in that group. 

The CCA secure construction of Yu et al. (6) in- 
volves updating the master key component of each 
attribute that has been revoked in the system. The 
public key components are then updated and data 
is encrypted with the new public key. Finally, proxy 
re-keys are generated that enable a proxy to update 
the user secret keys to the new version for all but 
the revoked user. Basically the re-keying burden in 
placed on the proxy, instead of users. We note that 
the existing data would need to be re-encrypted by 
the proxy; placing a significant burden on the system. 
While our scheme is only CPA secure under the 
generic group model (weaker security than Yu et al.), 
it does not require re-encryption of existing data. 

7.2 Proxy Based Re-encryption 

Our revocation techniques are based on the notion of 
proxy re-encryption. We will now briefly trace some 
developments in this field, and discuss why the state 
of the art techniques cannot be directly applied to our 
setting. 

Blaze et al. p7| introduced the notion of proxy re- 
encryption, in which a proxy could convert a ciphertext 
for Alice into a ciphertext for Bob, using a specially 
generated proxy key. The holders of public-key pairs 
A (Alice) and B (Bob) create and publish a proxy 
key tta^b such that Z)(7r(i?(ra, e^), 7Ta^b), <^b) = m, 
where E(m,e) is the public encryption function of 
message m under encryption key e, D(c,d) is the 
decryption function of ciphertext c under decryption 
key d, ^(c^tta^b) is the proxy function that converts 
ciphertext c according to proxy key ka^b, and e^, e#, 
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(La, (Lb are the public encryption and secret decryption 
component keys for key pairs A and B, respectively 
In the El-Gamal based construction proposed by Blaze 
et al., while the proxy cannot see the plaintext mes- 
sage m, it can collude with B to recover the secret key 
for A. Moreover, the construction is bidirectional, and 
the proxy key can be used to convert ciphertext for 
Bob into a ciphertext for Alice as well. 

Ateniese et al. (28) propose unidirectional protocols 
for proxy re-encryption based on bilinear maps, where 
a re-encryption key from A to B does not imply a 
re-encryption key from B to A. Canetti and Hohen- 
berger (29) proposed the first CCA secure bidirec- 
tional proxy re-encryption scheme, while Libert and 
Vergnaud [ 30 1 proposed the first CCA secure unidi- 
rectional proxy re-encryption scheme in the standard 
model. We note that all of the above schemes are lim- 
ited to the public key setting. Green and Ateniese |31| 
extended the model to the identity based setting 
by proposing a scheme for identity based proxy re- 
encryption, but it was not until Liang et al. |32| that 
the attribute based encryption setting was considered. 

In the attribute based setting of Liang et al., a 
user could designate a proxy, who can re-encrypt a 
ciphertext with a certain access policy into another 
ciphertext with a different access policy. Furthermore, 
the authors showed their scheme to be selective- 
structure chosen plaintext secure. However, it is not 
possible to apply their construction to the problem of 
attribute revocation because their construction does 
not support negative attributes. 

7.3 Social Network Privacy Architectures 

We will now describe existing social network privacy 
architectures and provide a comparison with EASiER. 
We can categorize the different schemes based on the 
level of trust for centralized services: a) trusted central 
servers, b) untrusted central servers, and c) decen- 
tralized architecture. Intuitively, decentralized archi- 
tectures provide the highest level of privacy. EASiER 
is close to Persona |7|, which is the state-of-the-art 
decentralized architecture for social network privacy. 
In almost all of the settings, access control is per- 
formed via encryption. We believe that the public key 
encryption setting is not well suited for fine-grained 
access control. Instead, PIRATTE uses attribute based 
encryption techniques to enable users to perform fine- 
grained access control. Moreover, none of the schemes 
focus on the issue of efficient user /attribute revoca- 
tion. 

Trusted Centralized Architectures: Lucas and 
Borisov [9 1 propose flyByNight, a facebook appli- 
cation designed to mitigate privacy risks in social 
networks. flyByNight users encrypt sensitive mes- 
sages using JavaScript on the client side and send 
the ciphertext to some intended party, i.e., Facebook 
friends, who can then decrypt the data. The architec- 
ture ensures that transferred sensitive data cannot be 



viewed by the Facebook servers in an unencrypted 
form. However, the utility of flyByNight is limited to 
preserving the privacy of messages intended for social 
network friends, i.e., email type communication, and 
thus, it does not provide complete privacy. For exam- 
ple, the application server knows a user's friendlist 
on facebook. flyByNight is also vulnerable to active 
attacks by the OSN provider, since the OSN interface 
is used for key management. 

Singh et al. (33) propose the xBook framework for 
building privacy preserving social network applica- 
tions. xBook uses information flow models to control 
what untrusted applications can do with the infor- 
mation they receive. Their design retains the func- 
tionality offered by existing online social networks. 
xBook provides enforcement for both user-user access 
control for data flowing within a single application, as 
well as for information sharing with entities outside 
xBook. Social network applications are re-designed to 
have access to all the data that they require, but this 
data is not allowed to be passed on to an external 
entity unless approved by the user. 

Untrusted Centralized Architectures: Guha et 
al. (8| propose to improve user privacy while still 
preserving the functionality of existing online social 
network providers. Their architecture is called None 
of Your Business (NOYB), in which encryption is used 
to hide the data from the untrusted social network 
provider. The key feature of their architecture is a 
general cipher and encoding scheme that preserves 
the semantic properties of data such that it can be 
processed by the social network provider oblivious to 
encryption. A user's private information is partitioned 
into atoms, and NOYB encrypts a user's atom by 
substituting it with the atom of another user. Thus 
the OSN can operate on ciphered data, but only the 
authorized users can decrypt the result. 

Anderson et al. (34) propose a client-server archi- 
tecture for providing social network privacy. In their 
design, the server is a very simple untrusted social 
network provider which serves as a data container, 
while a complex client side architecture performs the 
access control. The server only provides availability 
and client is responsible for data confidentiality and 
integrity. In addition to content data, the architecture 
is also able to protect the social graph information. 

Decentralized Architectures: As described earlier, 
Persona [7| is the state-of-the-art decentralized archi- 
tecture for social network privacy. EASiER is similar to 
Persona as both use ABE, but EASiER also provides an 
efficient mechanism for revocation, thereby avoiding 
the overhead of re-keying with group members as 
well as re-encryption of old data. 

In the approach by Shakimov et al. (35), users 
store their data in a Virtual Independent Server (VIS) 
owned by themselves. These VISs form an overlay 
network per OSN. The authors consider different 
types of decentralized OSNs, depending on where the 
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VISs reside: a) cloud b) desktop , and c) hybrid based, 
and compare their privacy, costs and availability Di- 
aspora pi) is a decentralized OSN that users install 
on their own personal web servers. Backes et al. |36| 
present a core API for social networking, which can 
also constitute a plug-in for distributed OSNs. They 
assume that the server is trusted with the data while 
implementing access control. Both of these approaches 
avoid encryption. 

PeerSon (37), LotusNet (38) and Safebook (39), 
three decentralized designs for social networking ben- 
efit from DHTs in their architecture. PeerSon and 
Safebook suggest access control through encryption, 
but they fall short in providing fine-grained policies 
comparing to ABE-based access control. Safebook is 
based on a peer-to-peer overlay network named Ma- 
try oshka. The end-to-end privacy in Matry oshka is 
provided by leveraging existing hop-by-hop trust. In 
all of these schemes overhead of key revocation affects 
performance. 

8 Conclusion 

We presented a scheme called PIRATTE for efficient 
revocation in Ciphertext Policy Attribute-based Encryp- 
tion. We achieved this revocation scheme by intro- 
ducing a semi-trusted proxy, leveraging ideas from a 
group communication scheme, and combining it with 
ABE. We also presented an architecture named EAS- 
iER for Online Social Networks (OSNs) that enforces 
access control through encryption using techniques in 
PIRATTE. Although we showed the use of PIRATTE 
in an OSN setting, it can be applied to any context 
where ABE is used for data protection with dynamic 
group membership. We implemented the scheme and 
compared it with Bethencourt et al/s CP- ABE. Our 
results show that PIRATTE is scalable in terms of com- 
putation and communication for OSNs; accordingly, 
we have built a prototype application in the Facebook 
OSN to provide such encryption. 
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